磐舟一體化云交付平臺是中國移動自主研發(fā)的面向開發(fā)人員的代碼開發(fā)，自動部署的平臺。磐舟一體化交付平臺自研實現(xiàn)了一套GitOps驅(qū)動引擎，支持從需求設(shè)計、開發(fā)構(gòu)建、測試部署的全部開發(fā)與運(yùn)維功能需求，實現(xiàn)應(yīng)用一鍵上磐基容器云平臺。

磐基容器云平臺是中國移動信息公司基于Kubernetes構(gòu)建的企業(yè)級PaaS解決方案，實現(xiàn)Kubernetes能力的標(biāo)準(zhǔn)化封裝及調(diào)用，包括提供開發(fā)和運(yùn)行環(huán)境、資源彈性伸縮、精細(xì)化微服務(wù)管理、便捷一站式服務(wù)、跨地域多集群調(diào)度和智能監(jiān)控維護(hù)等六大能力。

磐舟和磐基是相互配合的，開發(fā)人員在磐舟集群上開發(fā)，部署到磐基PaaS集群上運(yùn)行應(yīng)用，也支持在磐舟上歸檔磐基集群ops配置，通過GitOps來管理、部署磐基集群。

隨著國產(chǎn)化進(jìn)程推進(jìn)，中國移動建設(shè)了大量的國產(chǎn)化服務(wù)器集群，磐基磐舟如何實現(xiàn)國產(chǎn)化的容器云開發(fā)交付一體化體系?在某資源池我們需要統(tǒng)一管理近500臺鯤鵬服務(wù)器，源碼可以通過磐舟統(tǒng)一編譯為X86/ARM雙架構(gòu)的鏡像，但是集群的管理也需要實現(xiàn)ARM自動化支持，開發(fā)交付環(huán)節(jié)頻繁使用Kubernetes集群，最近2個月已有800多次的集群創(chuàng)建回收動作，人工支撐顯然已經(jīng)跟不上云原生的發(fā)展速度了。

另一個場景是，移動的開發(fā)人員在集團(tuán)磐舟Kubernetes集群上進(jìn)行開發(fā)，制作好鏡像后，不能直接推送到省測公司的Kubernetes集群，需要運(yùn)維人員在磐基中心集群上通過多級ssh跳板機(jī)，手工登錄到省公司磐基K8s集群進(jìn)行部署。這一步?jīng)]有實現(xiàn)自動化，操作流程十分繁瑣。

想解決這些問題，我們進(jìn)行了一些頭腦風(fēng)暴。

首先是考慮是否可以將集群統(tǒng)一?答案顯然是不行。因為集團(tuán)k8s集群，由于業(yè)務(wù)不同，不能和省公司的k8s集群合為一體。

那么是否可以做k8s的集群聯(lián)邦?目前集團(tuán)集群與省公司集群之間可能是比較遠(yuǎn)的(跨省)，集群聯(lián)邦的整體消耗會大一些，并且目前跳板機(jī)的場景，跳到省公司集群一臺機(jī)器上就夠了，不需要看到省公司的所有機(jī)器。

維持ssh現(xiàn)狀，維護(hù)shell腳本?shell腳本需要人力維護(hù)，在省公司的節(jié)點(diǎn)邏輯很可能需要使用service來完整，繼續(xù)維護(hù)shell，第一不是那么CloudNative，第二也背離了磐基磐舟輕松上云的初衷。

本著達(dá)到靈活、易用，提升集群部署時效，解決端到端開發(fā)運(yùn)維效率，成就內(nèi)部客戶的目的，我們針對整體場景做了進(jìn)一步抽象，抽象成“1+31+N”的典型網(wǎng)絡(luò)模型。

1個中心+“31+N”個邊緣集群的場景，中心與集群、集群與集群，集群與N之間，存在著網(wǎng)絡(luò)隔離與網(wǎng)絡(luò)不可預(yù)知的情況;在這些集群之間，保持網(wǎng)絡(luò)隔離的情況下，在中心節(jié)點(diǎn)做到云原生體驗的自動化運(yùn)維，做到GitOps自動化。

帶著抽象之后的這個模型，我們在平臺管理上進(jìn)行了深入調(diào)研，最終選用了CNCF的邊緣計算項目KubeEdge來解決完成以上所有集群的統(tǒng)一管理。

KubeEdge是什么?解決什么問題?

KubeEdge的特點(diǎn)是在云邊通信的資源消耗小，使用方式基于Kubernetes，上手方便，比較適合我們當(dāng)前的場景。KubeEdge項目是華為云開源的一個基于Kubernetes的開放平臺，并為網(wǎng)絡(luò)應(yīng)用提供基礎(chǔ)架構(gòu)支持，提供云和邊緣之間的部署和元數(shù)據(jù)同步。

KubeEdge具有以下幾點(diǎn)關(guān)鍵優(yōu)勢：

1)容器化應(yīng)用封裝

Build once, run anywhere

輕量化基礎(chǔ)鏡像，降低資源占用

2)通用的應(yīng)用抽象定義

業(yè)界事實標(biāo)準(zhǔn)

云上、邊緣統(tǒng)一管理

3)松耦合的架構(gòu)

易擴(kuò)展的API框架

易于定制平臺組件

KubeEdge 在架構(gòu)上分為云端組件 CloudCore 和邊緣側(cè) EdgeCore，詳細(xì)的架構(gòu)細(xì)節(jié)可以參考文檔：https://docs.kubeedge.io/en/docs/architecture/

磐舟磐基平臺的KubeEdge實踐

通過對KubeEdge的應(yīng)用場景分析，以及對移動內(nèi)部1+31+N模型結(jié)合，我們可以將集團(tuán)的“1”想象為KubeEdge的CloudCore節(jié)點(diǎn)、將各省公司的node節(jié)點(diǎn)想象為EdgeCore節(jié)點(diǎn)，從而就實現(xiàn)了1+31+N下的云邊協(xié)同模型。映射到我們的具體場景是這樣：

1)集群業(yè)務(wù)部署場景：

把集團(tuán)的K8s master節(jié)點(diǎn)作為KubeEdge的CloudCore節(jié)點(diǎn)，省公司的node節(jié)點(diǎn)作為KubeEdge的EdgeCore節(jié)點(diǎn)，CloudCore節(jié)點(diǎn)與EdgeCore節(jié)點(diǎn)連接上后，在EdgeCore上啟動磐舟GitOps業(yè)務(wù)中ArgoCD pod，統(tǒng)一下發(fā)CD一體化的元數(shù)據(jù)，從而將省公司資源池做到方便的集群創(chuàng)建、集群納管，最終方便的達(dá)成自動化GitOps交付。

2)集群自動化創(chuàng)建場景：

基于省公司的資源池來創(chuàng)建磐基PaaS集群，運(yùn)維人員在master節(jié)點(diǎn)使用磐舟GitOps，通過CloudCore與EdgeCore的通信，部署來自openEuler社區(qū)的集群自動化部署工具-eggo的實例。之后在邊緣側(cè)，就可以通過eggo來自動化完成省公司磐基PaaS集群的創(chuàng)建。

綜上，通過將KubeEdge集成至磐基PaaS平臺，成功打通移動集團(tuán)與各省公司的網(wǎng)絡(luò)，實現(xiàn)“1+31+N”的K8S集群全部連通、實現(xiàn)統(tǒng)一管理、簡化多集群的運(yùn)維系統(tǒng)、減少運(yùn)營成本;同時也成功將前面提到的500臺鯤鵬服務(wù)器以及它上面的BC-Linux for Euler集群納入磐基PaaS平臺的大家庭之中，運(yùn)維效率大幅增加。

磐舟磐基平臺在多集群管理的下一步計劃

在完成KubeEdge集成到磐舟磐基平臺這項專項工作之后，考慮到后續(xù)不僅是由master節(jié)點(diǎn)納管單個edge節(jié)點(diǎn)，還會考慮在將南向集群的單個節(jié)點(diǎn)組成一個集群，實現(xiàn)控制面的自動化集群部署，支撐省公司集群的控制面自動化。磐舟磐基平臺計劃進(jìn)一步集成CNCF社區(qū)最新的集群聯(lián)邦方案Karmada來完成“1+31+N”的PaaS多集群統(tǒng)一管理工作。

關(guān)鍵詞： 磐舟一體化云 中國移動 企業(yè)級解決方案 開發(fā)平臺